JAWS DAYS 2019 に行ってきた

sell
aws jaws-ug report
Contents

JAWS DAYS 2019に行ってきました。

下記は、自分が聴講したセッションのメモとスライドのリンクです。

[アーキテクチャ]今日からはじめるCI/CD…のためのAWSアーキテクチャ事始め

夫婦喧嘩からはじまるCI/CD

  • webサーバ2台のサービス規模だとしても、それさえ手動で構築は面倒。 -> CI/CDを導入してはどうか、という会話になった。
  • 今後サーバ台数を増やしたいときも手動？それはどうなの？
  • 導入するメリットは？
    • 手動ではなくAutoScalling
    • updateやbugfixを、手動の上書きではなくImmutableに運用したい
    • 将来サービスをインスタンス化、マイクロサービス化したいなら、なおさら導入するべき

CI/CDとAutoScallingは違う。
まずはCI/CDを分けて考える。

CI(Continous Integration)

  • 開発の本質
    • bugの早期発見および対処。
    • softwareの品質向上。

CD(Continuous Delivery/Deployment)

  • Delivery
    • 承認がないと本番にデプロイできないことがある。
  • Deployment
    • 継続的に行えること。
    • deployに無駄な時間をかけずに迅速に対応できること。

システムの品質向上が目的

  • 何のためのシステム？ etc. カスタマー向け、企業ユーザ向け、社内向け

リソースの属人化や権限の縦割りって無駄。

  • 開発者自身が自由にリリースできる方が良い。
  • リリース権限者がボトルネックになる可能性。
  • リリース権限の縦割り、が古い考え方。

CDからはじめるほうがお手軽

  • CI/CDを一気に導入するのは考えることが多くてたいへん。
  • 既存プロジェクトに後からCI導入は難しい。
  • CIやるにはテストコードが必要なので、CD (deploy) だけでも自動化してみる。
  • 非コンパイル言語ならCDだけでもやって見る価値あり。
  • リリース頻度が週1,2回以上ならなおさらやるべき。

今日からはじめるCI/CD by 波田野 裕一さん

"サービスに自分たちを合わせるのではなく、自分たちのパイプラインにサービスを組み込む" by SA大村さん

CI/CDのデザインマップ

  • 自分たちのパイプラインの行き先はユーザ。
  • ツールに精通しても時代が変われば意味がない。
  • パイプラインの行き先がユーザになっていれば、使用されているツールはなんでもよい。

[ハイブリッドクラウド] クラウドからオンプレを管理する！ AWS の Management Tools を使ったハイブリッドアーキテクチャ
by大村幸敬さん

[IoT]IoT野郎が語り合う、IoTの今と未来、そしてエコシステム

こちらはTwitter(#iot野郎)でお題を募集するパネルディスカッション形式でした。

コミュニティとエコシステム

  • 情報を取り入れるだけでなく、情報を交換するのがコミュニティ。
  • 昔はEC2だっておもちゃだと思われていた。 RaspberryPiもそう。
    • やったことはだいたいLinux上で動く。
  • "やってみた"は全量の2割くらい。
  • "やってみた"で終わらせない。
  • AI関連の案件が増えてきた。
  • connectedな製品が増えてきた。
  • ビジネス領域は、機能面でも、費用面でも増えてきている。
    • できることが、どんどん製品に取り込まれて増えてきた。
    • 開拓者に追随した人が新たに何かやる、というのが増えている。
  • 世の中にないものをIoTで、という事例が増えている。
  • やり方はさておき、必要性は感じる。人よりもIoT機器の数が膨大になり管理しきれず、攻撃の踏み台にされる心配がある。
  • ハードウェアに出荷前の段階で、証明書を入れたりする作業は結構コストになる。
  • 企業内の設備はセキュリティがゆるい。 ベンダー側からはお客様に啓蒙していかなくてはならない。
  • 日本はICTへの施策は奥手だった。 世界の先陣きって実施する姿勢はよい。
  • データ量を要求される。
    • 動画のストリーミングだったり。
    • 機械学習だと避けては通れない。
  • センサー側のコード化。
    • ただデータを送るのではなく、画像ならフレームの差分だけ抽出して、できるだけデータ通信量を抑える。
  • IoTでビジネスをしたいのであれば、クラウドは手段なので言ってしまえばどこでもいい。
  • Greenglassなどのサービスを先陣きってやってくるのがよい。

IoTとエコシステム

  • お客様は、導入までの手数を減らしたいはず。
    • IoTセレクション。 ソリューションをそのまま借りることができる。

[Others]Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する

[CLI]AWS CLIではじめるコマンドラインライフ 〜 正しい「運用自動化」への第一歩 by波田野裕一さん

"GUIは中学生まで"
"運用自動化" よりも "運用構造化" の未来へ

GUI

  • なんとなく理解していれば、つつがなく作業完了(ほんとに？)
  • なにか起きたときに対応できる知見がつかない
  • GUI手順作成は、CUIの3倍の手間、1/3の品質
  • UI改訂のあおりを受ける

CUI

  • コマンドやAPIなど低レベルで機能を理解して作業。
  • 一歩ずつ確実に知見を積み上げることができる。

AWSサービスはAPIの集合体

  • AWSは全ての機能をAPIで提供している。
  • "AWSを真に理解する"とは"AWS APIの仕様を理解する"こと。

AWS CLIのバージョンは週4〜5回更新。

  • GUIでできないけどCLIならできることが4000以上。
  • 後回しにすればするほど学習コストが高くなる。
  • 変更差異が確実にわかるのでundoができる。
  • ちなみにCloudFormationで対応しているサービスは、全サービスの半分以下。

AWS CLI利用方法

  • 何はともあれ公式リファレンス。
  • 補完機能
  • 強力なJAMESPath.
    • 出力結果から特定のノードを取り出すことができる。

運営スタッフの皆様、登壇者の皆様、スポンサーの皆様
本当にありがとうございました。

← Posts